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Abstract 

Specification and [visual] modelling languages are expected to combine strong abstraction mech- 
anisms with rigour, scalability, and parsimony. LePUS3 is a visual, object-oriented design descrip- 
tion language axiomatized in a decidable subset of the first-order predicate logic. We demonstrate 
how LePUS3 is used to formally specify a structural design pattern and prove (‘verify’) whether any 
Java™ 1.4 program satisfies that specification. We also show how LePUS3 specifications (charts) 
are composed and how they are verified fully automatically in the Two-Tier Programming Toolkit. 

Keywords: specification, automated verification, visual languages, design description languages, 
object-oriented design 
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1 Context 

Software systems are the most complex artefacts ever produced by humans [1][2], and managing com- 
plexity is one of the central challenges of software engineering. According to the second Law of Software 
Evolution [3], complexity also arises because most programs are in a continuous state of flux. Maintain- 
ing consistency between the program and its design documentation is largely an unsolved problem. The 
result is most often a growing disassociation between the design and the implementation layers of rep- 
resentation [4]. Formal specification of software design and tools that support automated verification 
are therefore of paramount importance. Of particular demand are tools which, by a click of a button, 
can conclusively establish whether a given implementation is consistent with (‘satisfies’) the design. 
Attempts towards this end include Architecture Description Languages (ADLs) [5] and formal pattern 
specification languages [6]. Specifically, we are concerned with the following set of desired criteria: 

• Object- orientated: suitable for modelling and specifying the building-blocks of the design of 
object-oriented programs and patterns 

• Visual: specifications serve as visual presentations of complex (possibly hypothetical) systems 

• Parsimonious: represent complex design statements parsimoniously, using a small vocabulary 

• Scalable: abstraction mechanisms that scale well such that charts do not clutter as the size of 
programs increase 

• Rigorous: mathematically sound and axiomatized such that all assumptions are explicit 

• Decidable: fully-automated formal verification is possible at least in principle 

• Automatically verifiable: accompanied by a specification and (fully automated) verification tool 

LePUS3 (LanguagE for Patterns Uniform Specification, version 3) is an object-oriented Design Descrip- 
tion Language [7] tailored to meet these criteria. It is particularly suited to representing design motifs 
such as structural and creational design patterns. LePUS3 ‘charts’ are formal specifications, each of 
which stands for a set of recursive (fully Turing-decidable) sentences in the first-order predicate logic. 
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LePUS3 logic is based on Core Specification Theory [8] which sets an axiomatized foundation in math- 
ematical logic for many formal specification languages (including Z, B, and VDM). The axioms and 
semantics of LePUS3 are defined using finite model theory. The relation between LePUS3 specifications 
(charts) and programs is well-defined [9] (formulated using the notion of an Abstract Semantics func- 
tion) and the problem of satisfaction is Turing-decidable. Furthermore, consistency between any LePUS3 
chart and a standard Java 1.4 [10] program — henceforth, the problem of verification — can be established 
by a click of a button. This quality is demonstrated with the Two-Tier Programming Toolkit (discussed 
in §6), a tool which fully automates the verification of LePUS3 charts against Java 1.4 programs in 
reasonable time. 
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Figure 1 : LePUS3 vocabulary, some visual tokens not used in this paper were omitted 


The detailed syntax, axioms and truth conditions which constitute the logic of LePUS3 are laid out 
in [11]. Due to space limitations, our presentation focuses on a single example of the specification and 
verification of an informal hypothesis. LePUS3 also effectively specifies many other design patterns [12] 
and the design of object-oriented class libraries encoded in any class-based programming language (e.g. 
C++, Smalltalk). However, to maintain decidability the language is largely limited to the structural an 
creational aspects of such designs. In §2 we define informally our initial informal hypothesis, which we 
refine in §3 and §4 by specifying the design in LePUS3 and offer an abstract representation (‘abstract 
semantics’) of the implementation, respectively. In §5 we present a logic proposition that formalizes our 
original hypothesis and prove it. In §6 we present a tool which fully automates the verification process 
and discuss an experiment we are currently undertaking, which will test our predicted benefits in program 
comprehension, conformance and maintenance. 

2 The problem 

As a leading example we focus on a common claim (e.g. [13][14][15]) that the package java.awt in 
version 1.4 of the standard distribution (‘Software Development Kit' [16]) of the Java programming 
language [10] ‘implements’ the Composite design pattern, quoted in Hypothesis 1. 

Hypothesis 1 . java.awt implements the Composite design pattern 

In this section we examine the informal parts of Hypothesis 1 : the Composite design pattern and 
package j ava.awt. The remainder of this paper is dedicated to formalizing and verifying this hypothesis. 

2.1 The Composite Design Pattern 

Design patterns have made a significant contribution to software design, each describing an abstract 
design motif — a recurring theme which in principle can be implemented by an unbounded number of 
programs in any class-based programming language: 
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A design pattern names, abstracts, and identifies the key aspects of a common design struc- 
ture that make it useful for creating a reusable object-oriented design . . . Each design pattern 
focuses on a particular object-oriented design problem or issue. [17] 

Table 1 quotes the solution advocated by the Composite design pattern. As is the custom of most pattern 
catalogues, it is described informally. 


Intent: Compose objects into tree structures to represent part-whole hierarchies. 

Participants: 

- Component: Declares a basic interface, implementing default behaviour as appropriate. 

- Leaves: Have no children, implements/extends superclass behaviour as appropriate. 

- Composite: Has children, defines behaviour for components having children. 

Collaborations: Interface of Component class is used to interact with objects in the structure. Leaves handle requests 
directly. Composite objects usually forward requests to each of its children, possibly performing additional operations 
before and/or after forwarding. 


Table 1: The Composite design pattern [17] (abbreviated) 


2.2 Package java. awt 

Package java. awt (‘Abstract Window Toolkit') is part of the standard distribution of Java Software 
Development Kit 1 .4 [16] which provides user interface widgets (e.g. buttons, windows, etc.) and graphic- 
operations thereon. Class Component represents a generic widget that is extended [in]directly by all non 
menu-related widgets (e.g. Button, Canvas). Container represents widgets which aggregate (hold an 
array of instances of) widgets. Excerpts of the package’s source code that corroborate Hypothesis 1 are 
provided in Program 1. All references to java. awt shall henceforth refer exclusively to those aspects 
listed in Program 1 . 

public abstract class Component ... { 
public void addNotifyl) ... 
public void removeNotify () ... 

protected String paramString () ... } 

public class Button extends Component ... { 
public void addNotifyf) ... 
protected String paramString () ... } 

public class Canvas extends Component ... { 
public void addNotifyf) ... 
protected String paramString () ... } 

public class Container extends Component { 

Component component [] = new Component [ 0 ] ; 
public Component f] getComponents () ... 

public Component getComponent ( int ) ... 

public void addNotifyl) { component [ i ]. addNotify () ; ... } 

public void removeNotify)) { component f i ] . removeNotify () ; ... } 

protected String paramString)) { String str = super . paramString () ; ... } ... } 

Program 1: java. awt [16] (abbreviated) 


3 Specification 

Most contemporary modelling languages [18] and notations offer a means of representing implemen- 
tation minutiae. Design patterns however describe design motifs: abstractions that are not tied in to 
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specific programs. Therefore, the representation of design patterns requires accurately capturing generic 
abstractions involving collections of entities (e.g. ‘ composite ’, ‘ component ’) that are characterized not 
by a particular implementation but by their properties and relations (e.g., ‘ composite is a class that has 
children of type component’). Our Design Description Language must therefore be useful in represent- 
ing generically, among others, the category of entities and relations which constitute the building-blocks 
of design patterns, namely [sets of] classes, [sets of] methods, and their correlations. 


[ij TTP Toolkit - 0.5.2 

File Model Specify Verify Navigate Window Help 


lid Chart - Composite 

lafc^^omtynEi-tktsss € $>mm 



Chart 1: The Composite design pattern specified in LePUS3 (chart Composite) using the TTP Toolkit 

LePUS3 was tailored specifically for this purpose, while keeping focus on automated verification. 
For example chart Composite (Chart 1) captures much of the informal description of the Composite 
design pattern (Table 1). A LePUS3 chart consists of a set of well-formed formulas, each of which is 
composed of a well-formed combination of visual tokens (Figure 1). Each formula consists of terms, 
which stand for [sets of] classes or [sets of] methods, a relation and possibly a predicate symbol, which 
represent correlations between the entities being modelled. The meaning of chart Composite is captured 
by the truth conditions spelled out in Table 2. 

Given the formal specification of the pattern and the truth conditions of satisfying this specification, 
we may now rephrase our informal hypothesis in slightly more rigorous fashion as demonstrated in 
Hypothesis 2: 

Hypothesis 2. java.awt ‘implements’ chart Composite 

4 Abstract Semantics 

When speaking of a ‘program’ or an ‘implementation’ we usually refer to the source code, normally 
represented by a complex collection of text files describing myriad implementation minutiae distributed 
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Terms 

(a) composite and component are variables ranging over individual types (in Java: class, interface, or primitive type) 

(b ) Leaves is a variable that ranges over sets of types 

(c) CompositeOps and ComponentOps are variables ranging over sets of method signatures 

Formulas 

(d) composite must have an ‘aggregate' (an array or a Java collection) of instances of type component (or of subtypes 
thereof) 

(e) composite must ‘inherit' (in Java: extend or implement) (possibly indirectly) from class component 

(f) Every class in Leaves must ‘inherit’ (possibly indirectly) from class component 

(g) composite must define (or inherit) a method for each of the signatures in the set CompositeOps 

(h) Every class in Leaves must define (or inherit) a method for each of the signatures in the set ComponentOps 

(i) Each method defined in (or inherited by) composite, with a signature in ComponentOps, must at some point forward the 
method call (invocation) to that (unique) method with same signature that is a member of (or inherited by) component , and 
vice versa 


Table 2: Truth conditions for chart Composite 


across a directory structure. Source code is a difficult medium to reason about, not the least so because 
in practical circumstances it normally contains thousands (or millions) of lines of code. For example, the 
unabbreviated source code of only four classes from java, awt spans over ten thousand lines. Reasoning 
therefore requires a simplified picture of the program, hence the motivation for introducing the notion of 
abstract semantics. 

In this context, an abstract semantics is a finite structure in model theory, which is simply a set of 
atomic entities and relations between them (implemented as a set of tables in a relational database). 
Specifically, a finite structure $ [1 1][19] is a pair $ — (U,R) where U (the ‘universe’ of 5) is the (finite) 
set of all (atomic) entities, and R is the (finite) set of relations between them, e.g.: 

U ={ Container addNotifvO } (1) 

R ={ Class , Method , Signature , Inherit , Aggregate , . . .} (2) 

Note that to maintain their distinction, items in the model are underlined . Each atomic entity in the 
universe U is a class (an element of the unary relation Class ), a method, (an element of Method ) or 
a method signature (an element of Signature , which identifies method name and argument types). In 
other words, U is the (disjoint) union of the unary relations Class , Method and Signature . Each 
unary (binary) relation in R is a finite set of 1 -tuples (2-tuples) of atomic entities. For example, the 
unary relation Class is a set of 1 -tuples, one for each of the four classes in java. awt. The binary 
relation Inherit is a set which contains all the pairs of types (cls,supercls) in java. awt such that els 
extends/implements/is-subtype-of supercls. Likewise, the binary relation Aggregate contains pairs 
of classes (cls,elementType) such that els contains a collection (or array) of instances of the class 
elementType (or subtypes thereof). The binary relation Forward represents a special kind of method 
call between two methods, (invoker, invoked), that share the same signature. 

The precise relation between a program and its abstract semantics is formally captured using the 
abstract semantics function: a mapping from programs (expressions in the programming language) into 
finite structures. For example, Aj ava \A [9] is an abstract semantics function which represents the mapping 
from each Java 1.4 program to a finite structure. 

AjavaiA : JAVA 1 .4 1 — > 3* (3) 

where JAVA1.4 stands for the set of all well-formed Java 1.4 programs and J* stands for the (enumer- 
able) set of all possible finite structures. 
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Abstract semantics functions allow us to determine exactly how the source code of programs can be 
abstracted. For example, we may use Aj ava \A to define the finite structure for j ava.awt as follows: 

A j m a l .4 ( j ava . awt ) (4) 

We require that abstract semantics functions are fully Turing-decidable such that they always terminate; 
in practical terms this means that Aj ava \ 4 can, in principle, be implemented as a static analyzer. Such 
an analyzer is implemented in the Two-Tier Programming Toolkit (§6), a tool which parses any Java 
1.4 program and generates a representation of a finite structure therefrom (a relational database) [9]. 
However, static analysis is not without its limitations, and as such we do not currently capture much of 
the behavioural aspects of programs, for example temporal information and program state. 

Alternatively, other abstract semantics functions can be equally used to represent programs in any 
class-based object-oriented programming language (e.g. C++, C#, Smalltalk). For example, if an abstract 
semantics function is defined for the C++ programming language: Ac++ : C + + 1 — > the very same 
specification and verification mechanisms described in this paper can be applied to programs written in 
C++. 

The notion of abstract semantics allows us to articulate informal claims concerning the relationship 
between a design pattern and a program precisely as a mathematical proposition. Specifically, we stip- 
ulate that a program p implements a design pattern if and only if the abstract semantics of p (a finite 
structure) satisfies that LePUS3 chart which specifies that pattern. Hypothesis 2 can thus be redefined in 
these terms as follows; 

Hypothesis 3. A/avai.4(j ava.awt) satisfies Composite 

In the following section we define this ‘stisfies’ relation, and recast Hypothesis 3 as a mathematical 
proposition. 

5 Verification 

By verification we refer to the rigorous, conclusive, and decidable process of establishing or refuting 
whether a particular program is consistent with a given LePUS3 specification (chart). An automated 
process of verification therefore consists of executing an algorithm which determines if a program p 
(modelled using the notion of abstract semantics) satisfies a LePUS3 chart T. 

The conditions for ‘satisfying’ 'F are modelled after the standard Tarski’s truth conditions for the clas- 
sical logic, as demonstrated in Table 2. A satisfies proposition is represented using the standard semantic 
entailment symbol |=, allowing us to recast Hypothesis 3 as the following (decidable) proposition: 

Hypothesis 4. A/ ava i.4(java.awt) ^Composite 

Charts modelling design motifs such as Composite contain variable terms. To show that such a chart 
is satisfied in the context of a specific program its variables must first be mapped to entities in the appro- 
priate finite structure. Such a mapping is commonly referred to as an assignment. Formally the semantic 
entailment in Hypothesis 4 holds if and only if there exists an assignment that maps each variable in 
Composite to specific elements of a given program, in this case j ava.awt. Such an assignment is pre- 
sented in Table 3, where the search for assignments is a matter of pattern detection and therefore beyond 
the scope of this paper. 

Hypothesis 4 can now be recast as a proposition such that the abstract semantics of j ava.awt satisfy 
the Com posite chart under assignment g, a claim represented in Hypothesis 5 using the standard notation. 

Hypothesis 5. A/ flva i.4(j ava.awt) \= g Composite 
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g (composite) 
g (component ) 
g(Leaves) 
g(ComponentOps ) 
g(CompositeOps) 


Container 
Component 
{ Button , Canvas } 

{ addNotif y() , removeNof ityQ , paramStringQ } 
{ get Components!) , getComponent! int) } 


Table 3: Assignment g mapping variables in Composite to entities in java.awt 


The proposition in Hypothesis 5 imposes specific conditions on the existence of specific entities and 
sets of entities in j ava.awt and on specific correlations amongst them. To prove it we refer back to Table 
2, which constitutes two kinds of conditions: 

1 . Truth conditions for terms. For example, class composite is satisfied by virtue of assignment g, 
and the 1 -tuple ( Container } in relation Class . 

2. Truth conditions for formulas. For example, the Inherit relation between class composite and 
class component is satisfied by virtue of g, and the pair ( Container , Component } in the relation 
Inherit . 

Table 4 is demonstrates the proof for Hypothesis 5, the precise elements of Aj ava \A( java.awt) which 
satisfy the truth conditions of Chart Composite (Table 2). 


...,( Container ), ( Component ) G Class 

h 

(a) 

. . . , ( Container , Component ) G Aeereeate 

H 

(d) 

...A Container . Component ) G Inherit 

h 

(e) 

( Container. getComponentsO ) G Method 

( getComponentsO , Container. getComponentsO ) G Signatured) f 

...,( Container , Container. getComponentsO ) G Member 

H 

(g) 

( Container. addNotif v() , Component. addNotifvO ) G Forward 

h 

(i) 


Table 4: Proof of Hypothesis 5 (abbreviated) 


From this proof we conclude that java.awt indeed satisfies the Composite pattern. While the notion 
of verification as demonstrated is straightforward, manually producing the proof is a tedious, error-prone 
process. Such proofs require the software designer to check the validity of hundreds and thousands 
of clauses. It also requires intimate knowledge of both the abstract semantics of the implementation 
and of the specification language. Worse, the proof process would have to be repeated each time the 
implementation, or the design, change. However, verifying LePUS3 charts need not be a Herculean 
manual task as it can be fully automated, as described in the next section. 

6 Tool Support 

The Two-Tier Programming project [20] has recently completed implementing version 0.5.2 of the Two- 
Tier Programming (TTP) Toolkit. The TTP Toolkit is a prototype that integrates the representation of 
programs in two layers of abstraction: the design — a set of LePUS3 charts, and the implementation — a 
set of standard Java 1.4 source code files. 

Our demonstration focuses on Figure 2, and begins with choosing the implementation (point 1); 
the TTP Toolkit supports the selection and static analysis (generating finite structures) of Java 1.4 
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source code, which in this case is the four .java files from java.awt (Button. java, Canvas. java, 
Component. java and Container. java). The TTP Toolkit also supports the composition and editing 
of specifications (LePUS3 charts), such as Chart Composite (point 2). Finally, the TTP Toolkit fully 
automates verification of programs against charts at the click of a button, such as the proof discussed in 
this paper. This is depicted by a window stating that verification was successful (point 3), as indicated 
by the text ‘PASSED’, as well as by a status message in the console. 
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Figure 2: Source files (1), chart Composite (2), and the verification result (3) in the TTP Toolkit 


Additionally, it is extremely important that when verification fails it generates a simple explanation 
so that the inconsistency between specification and implementation can be rectified. For example, con- 
sider reversing the forwarding relation in chart Composite, a change which will fail verification against 
java.awt. The TTP Toolkit symbolically reports this failure to the user (Table 5), clearly indicating 
where the problem originates in chart Composite. 


j ava. awt. Component. removeNot if y() does not forward to any of the entities in: 

{ j ava. awt. Container. removeNot if vQ , j ava. awt. Container. addNotif y( ) } 

Table 5 : Summary of the explanation provided by the TTP Toolkit on verification failure 
To summarize, the TTP Toolkit supports the following tasks: 
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• Specifying. The TTP Toolkit can be used to create, edit and view LePUS3 charts. 

• Analysing. The TTP Toolkit statically analyses any (arbitrarily-large) well-formed Java 1.4 pro- 
gram and generates a relational database representing its abstract semantics, defined by Aj ava \A- 

• Verifying. The TTP Toolkit can conclusively and efficiently determine whether a given imple- 
mentation satisfies a LePUS3 chart by a click of a button, and within reasonable time. 

The TTP Toolkit has also been used to model, specify and verify other cases than that presented here[20]. 
For example it has been used to prove that java.io package is not consistent with the Decorator design 
pattern [12][17], while adding evidence to the claim that said package is consistent with a variation of 
the pattern [15]. 

Indeed, specification need not necessarily precede verification; verification being just one of many 
tools that aid in the development and understanding of programs. Specifically the TTP Toolkit also 
supports reverse engineering and program visualization. The Design Navigator [7][21] is a design recov- 
ery tool that allows a user to navigate through the design of Java 1.4 programs by reverse-engineering 
LePUS3 charts therefrom. To do so, the Design Navigator creates the abstract semantic representation of 
programs, uses the verification engine to detect correlations between [sets of] classes and methods, and 
represents them at the appropriate level of abstraction. 

6.1 Empirical validation 

We believe that TTP Toolkit can dramatically increase the productivity of software engineers. To test 
this claim we have designed and started conducting an experiment that compares the TTP Toolkit against 
a standard commercial integrated development environment. The experiment measures the performance 
of (mostly postgraduate) students in carrying out a variety of tasks under controlled conditions, designed 
to test the following specific claims: 

• Comprehension: Effort required to understand the design and structure of arbitrarily-large pro- 
grams, measured in time, is significantly reduced; 

• Conformance: Overall dependability of programs, measured in terms of conformance of the im- 
plementation to the design specifications, can be significantly improved; 

• Evolution: The cost of software maintenance and/or re-engineering, measured in terms of time, 
can be significantly reduced. 

Preliminary results suggest that the TTP Toolkit radically decreases the length of time required to carry 
out software engineering tasks. 

7 Summary 

We presented LePUS3, an object-oriented Design Description Language, and demonstrated how LePUS3 
can be used to specify (model) design patterns. We re-formulated an informal hypothesis, which claimed 
that the Composite design pattern is implemented by the java.awt package, as a mathematical proposi- 
tion and sketched its proof. We also described the Two-Tier Programming Toolkit, a tool which can be 
used to compose object-oriented design specifications in LePUS3, statically analyse Java 1.4 programs, 
and verify them to establish whether they are consistent with the design specifications. Finally, we dis- 
cussed an experiment designed to test our claims concerning the Two-Tier Programming Toolkit. 
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